This forum is closed to new posts and
responses. Individual names altered for privacy purposes. The information contained in this website is provided for informational purposes only and should not be construed as a forum for customer support requests. Any customer support requests should be directed to the official HCL customer support channels below:
You described several different issues really so Ill try to cover them in order:
> When a meeting is created the resource room does not get saved in the RRDB nor does
> it send a confirmation indicating if the room is available or not. Our resource reservation
> database (RRDB) seems to have switched ownership to the Disaster Recovery
> clustered server.
The issue sounds like the client is unable to do a busytime check on the room the reservation is for so the template does the right thing and prevents you from saving the request. After all why let you save it if the room cannot be confirmed as being available for you. You would only have to come back and reschedule it later (assuming you came back and noticed that your request was Declined).
I cannot stress enough that you should strongly discourage direct bookings in the R&R dB. Allowing this just leads to abandoned rooms when meetings change and users forget to reschedule or free up rooms they no longer need. If they book from their Calendar, its all automatic so you get better utilization of your rooms. (Yes there is one tiny case where direct booking could be arguably nice to have but its just 1 case and it is more an edge case that does not outweigh the benefits of booking via C&S.)
As far as failing over goes, that should not matter. You can direct book, if you really must, in any replica at any time. The processing will only happen on the server which has control. We tested that case plenty before we added cluster support in 7.0 and its part of our own internal deployments so have no fear that the secondary server picked up control.
>Entering the command> tell RnRMgr whoowns Production\resources.nsf results in :
> 11/23/2010 04:06:27 PM Database Production\resources.nsf is currently under the control
> of server DR/<ourdomain> (0)
> This is our main cluster server for disaster recovery only. It is marked as 100% busy because
> we want to control when users switch over to it.
The primary server must have been down for over 30 minutes at some point so the R&R system did its normal cluster failover to the backup server.
The cluster availability of it has no bearing on the cluster failover for R&R; that happened because the primary server stopped responding to cluster probes entirely for at least 30 minutes.
As I mull it over a bit during my typing it could be that could affect the direct booking cases. All busytime lookups go to the users Home Server. From there the request would be routed to the primary R&R server for handling. If it were still down and your backup server was set to be unavailable then there would be no way for your Home Server to get the busytime data it needed and you get the results I described above.
All of this is just a though but something you can easily confirm by temporarily changing that threshold, doing a quick direct book test and then setting it back up and trying again. If it worked with the lower threshold than thats your problem (at least in the short term).
The busytime lookup from the users Home Server to the R&R server should go to the primary as long as its up. It sounds like it is though since you are trying to force users off the backup server and back to the primary one. In those cases the busytime lookup should work just like it does for users and get the data it needs from the primary server and so the direct booking should be possible.
You can see where the lookups are going (primary or secondary R&R server) by setting the DEBUG_SCHED_ALL=1 INI on both server and doing a test. You should see an incoming request trace on the primary R&R server (look for a line starting with RetrieveSchedule> on the console to start the trace). You can also set it on the testing users Home Server to see where it tries to go. Look for a line like: SchSrvRetrieveAsync> Queue request to server DR/<ourdomain>)
> How can I change the ownership of our RRDB back to the primary (Admin) server ? Have looked
> thru multiple postings and source talking about tell RnRMgr whoowns but not much on reassignment.
You cannot tell RnRMgr to do that. It is too cynical to believe everything it is fed on a command line. Ok, that last part is not true but you still cannot do it via a command.
If you have your heart set on forcing R&R processing back onto the primary server then it can be done. Simply make sure the primary server is back up and then take the backup server down for 30 minutes. This will trigger failover to occur once again (back to the primary server).
I feel obliged to point out that there is no technical need for you to force this. Users can still direct book in the replica on the primary server and the requests can be processed on the secondary as soon as they cluster replicate over. The only 'cost' to you is a couple extra seconds in cluster replication.
There is no demonstrable benefit to forcing R&R processing to only happen a particular, single server in a cluster. If you really wanted that you would not have clustered it would you? Still I would love to hear any motivation for needing this in case I simply overlooked something.
> Verified that the $Name field in the CLBUSY.nsf matches the $BusyName field in all resource
> rooms in the RRDB.
The issue sounds like one of accessing busytime rather than inaccurate data in busytime.
>Also, although these fail on the primary server with the following $BusyName fields, they do not fail
> if issued on the disaster recovery server (DR.)
> tell sched validate
> [0DB8:0002-0DBC] 11/23/2010 11:23:18 AM SchedMgr: Error processing calendar profile
> document (NoteID: NT0000BB0E) in database Production\resources.nsf: Can't find $BusyName
> field on profile
> tell rnrmgr validate
> [0DD0:0002-0DD4] 11/23/2010 11:26:02 AM RnRMgr: Error processing calendar profile
> document (NoteID: NT0000BB0E) in database Production\resources.nsf: Can't find $BusyName
> field on profile
Now that is interesting and mildly disturbing.
Both commands should demonstrate the same results on both servers. Since they do not I suspect your primary server has more docs in it than the secondary. That means your servers may not be properly replicating the R&R dB for some reason.
You should probably clear the replication history and then force replication of the R&R dB between both servers to see if that clear things up. If not, please open a ticket with Tech Support so they can dive on it with you to figure out whats going on.
As for the message, thats a long standing buglette that is due to a small logic hiccup when the first room or resource is added to the R&R dB. The template can create 2 profile docs instead of 1. The first one will have no $BusyName and the second one will. This is one error message you can safely ignore.
Or if you are so inclined and have some Agent coding skill you can create use an Agent to find and remove the offending doc You would only need to run it once as the blank $BusyName doc will not be recreated (at least not by the stock R&R template) do weigh that vs the effort it will take you to purge it out.
Bruce
IBM
Feedback response number BKAN8BQ5D3 created by ~Lex Nontookonynivu on 12/01/2010
You cannot command it
Return to top
. . You cannot command it (~James Preresas... 1.Dec.10) 
